A web application is a web site where users can access the information they need and change the state of application logic on a server through a set of web pages. Development of web applications is usually centered around tools and technologies. A web application centered around the Java™ technology may include the following: JSP™ pages and Java™ servlets that handle HTTP requests and generate dynamic content, server-side beans that encapsulate application behavior and state, static HTML files, DHTML files, image files, sound files, and libraries with additional Java™ components, such as client-side Java™ applets and any Java™ class files used by the other Java™ components. The J2EE™ specification describes a standard for how to organize such files into web modules, including describing how they are accessed. The web modules could be developed in an IDE, such as sold under the trade name Forte™ for Java™ by Sun Microsystems, Inc.
Now, suppose the user has identified a problem with how the input from one of the form fields in page A is processed by JSP_B, and say further that JSP_B is sufficiently complex that the cause of the problem cannot be immediately identified through inspecting the source. This means that the developer will need to employ some other tactic to identify the problem with the code. One such strategy is using a source level debugger. However, reproducing the request in a debugging section is a non-trivial task. First the user has to restart the HTTP server in debugging mode, a process that typically involves several steps. Then they have to start a debugging client and connect it to the server. Then they have to resubmit the request from Page A to the server that is now running in debugging mode. Clearly it would be desirable if the user can resubmit the request resulting from Page A without having to make a request for JSP_A and reenter the data into the resulting Page A's input fields. However, this may not be possible for several reasons. First, consider a portion of a web application that deals with entering billing and shipping addresses for the purpose of allowing the user to purchase goods or services. Assume that the web application includes page generation components JSP_A and JSP_B, respectively. Components JSP_A and JSP_B could be JSP™ pages, for example. JSP_A generates a page A that displays an HTML form in a browser where the user can enter billing and shipping addresses and press a “Continue” button to submit the information. Pressing the “Continue” button causes the browser to make a HTTP request to JSP_B with the data from the form fields as request parameters. If the address information is valid, JSP_B generates a page B which displays the addresses as text and asks the user to confirm that the addresses are correct. If the address information is invalid (e.g., because of a missing phone number or a zip code which contains characters other than digits), JSP_B forwards the request back to JSP_A, which regenerates page A with some extra messages that point to invalid entries.
Now, suppose that the user has identified a problem with how the input from one of the form fields in page A is processed by JSP_B. The user will attempt to fix the bug and then re-execute JSP_B with the same input from page A. In this situation, it is clearly desirable for the user to be able to resubmit the request from page A without having to reenter the same data into the page's input fields. However, this may not be possible for several reasons. First, it is common for dynamically generated pages to include a HTTP directive which specifies that the page should not be cached (by the browser or by a proxy server). This means that the browser's “Back” or “Reload” button would not populate the page's input fields with the previously entered data. Using the “Back” button would cause the form from which the HTTP request was created to be regenerated, losing any data that was previously entered. With reference to the example above, this means that if the user used the “Back” button to display page A, all the data the user previously entered on page A would be lost, so the user cannot just select the “Continue” button to resubmit the same request. The user can work around this by disabling the directive, but that involves extra work and remembering to enable it again later. Also, unless the developer can use the back button to redisplay Page_A with their original input, there is no simple way of making minor changes for the purposes of running the debugger with slightly different input
Once the developer has identified the problem and fixed it, they will want to return the execution server to its normal running mode to test the fix comprehensively. To do so, they will have to restart the server in normal running mode, and then send the same (and similar) requests for JSP_B again, which typically means repeating the process of invoking JSP_A and entering different input all over again.